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Looking at some of the user zroup newsletters that have been received here, 
(and by no means do we get more than half of them), one can conclude that the TS 
computer hobby is alive and well still. Particularly worthy of mention is the thid 
TS newsletter coming out of Toronto's User Group, which has increased coverage of l 
the QL, while retaining articles on the TS2068 and ZX-81 in every issue. The mater- 
ial tends to be fresh and TS specific as well, signs that the newsletter is healthy, 
If you see a newsletter starting to reprint cartoons from the local newspaper on the 
other hand, it is a sign that they are getting a little short on material and may 
even go under if you don't write something for them and mail it off, Luckily this 
newsletter that you have in your hands is facing a problem of too much material and 
not enough energy to proofread, edit and otherwise put it together into a newsletter, 
One solution to the problem of much material is being considered, that of this 
expanding to more than 8 pages, going back to the size it was when put on 84 xll 
inch paper, or at least occasionally reached, although that larger print format was 
soon abandonned due to the excessive postage required to mail it. (If this newsletter 
format is too small for you to read comfortably or photocopy a page off for your 
newsletter, you may wish to try what some readers are doing and take it to a copy 
shop where they have the reducing/enlarging photocopiers and blow it back up to the 
84 x 1l inch size.) More pages per newsletter, although it creates some problems for 
me, of a practical nature, does allow the inclusion of a longer article without then 
having any article dominate the issue, so if you are not interested in it, there is 
not too much else in that one issue, That is to try in the future however, 

But whv not? I noticed on getting a copy of the German QL User Group newsletter 
that their articles where often much longer than those I was used to publishing, so 
that convinced me to try longer articles, Another approach that this writer will be 
using is puttingarticles on disk, so that if they are published, the editor will have 
a chance to cut them after a page or two, or publish the shole thing, That isa trick 
this hobby of publishing may be teachingalthough none of the articles published here 
will be on disk. That is for the future and likely will mean a new Style article, 

Another thing that has changed with the last few issues of this newsletter, is 
that the editorial policy has been wavering between publishing more general material 
that is not TS specific and publishing more TS specific material. There is no policy 
on this; it is just the way the material comes together, Nonetheless, it seems we 
are moving in the direction of more TS specific material than less, these days. This 
issue for example discusses programming in n/c for the ZX-81/TS1000, including a m/c 
routine to substitute for the computer's built-in BASIC, INKEY$. It was interesting 
to discouver that serious mc programming is not the insurmountably hard thing to do 
afterall. Once you get past the first few attempts, where the learning curve is 
steep and many ddfficulties cluster, it does not seem so bad. Of course having a lot 
of reference books including a ROM disassembly and Sample programs to analyse, is 
just about essential in avoiding frustration, At any rate, some of the thinking anc 
Steps seemed worth sharing with the readers, in this voyage into m/c land. (p.3-0) 

The future will bring another set of occasional TS and hobby newsletters from here 
although some changes in the line up are being thought through now, We shall see, 
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\A page from our revised} D2 
More On LDOS SAVE/LOAD From A Running Program (ZX-8l1/TS1000 LDOS book . 

One small thing to note, is that LDOS returns from the disk operationsnot requiring 
LDOS to do screen print,in FAST mode. Therefore a SLOW should be inserted in any 
BASIC program after such a disk access or the m/c equivalent in a m/c LDOS disk 
access after the disk access (CALL OA2A hex, is the m/c way to access SLOW). 

A bug in LDOS may result in a program seeming to be saved, but the disk being full, 
not saved. Sometimes this results in an error and halt (return to LDOS screen on 
halt and display error message"disk full", the wayit should do, and sometimes it 
does not do that. The only clue is when you look at the directory you see opposite 
the name of the file, for blocks used, Ø (zero), in other words, not saved after- 
all. This may be a problem if you try to save work only once on one disk rather 
than making a second back-up. For that reason some extra lines are inserted in our 
listing #3, final version of a disk save routine, lines 9560, 9570, 9590 to 9598, 
but make sure these are deleted when you have stopped writing the program and want 
to make final copies for user group/commercial distribution, perhaps by using 
another disk save routine at another line location in the program for such making 
of copies for distribution of the program. 

In a program with some fairly extensive machine code, the calling of LDOS disk 
access functions is best illustrated in parallel with the easier to understand 
BASIC versions of these operations. To better understand POKE to CLINE and calling 
the LDOS command interpeter routine at address sort=14480,3890hex, look at the 
BASIC routine that does that, as shown in the ZX/TS LDOS book . (& See TS Bul.#3=92) 
Of course if you are saving some m/c. you may not want it saved as part of a normal 
BASIC program, the way the listing just mentioned would approach it. You may want 
to save it using the code save feature of LDOS where any block of RAM can be saved 
on disk, even if relocated to a non-standard area with respect to normal use in 
ZX-81/ TS1000 BASIC programs, Such a code save can be done from BASIC with POKE to 
get the starting address of the block to be saved on disk and its length, or the 
mc equivalent of POKE can be used, LDOS does not make any Speéial use of Z-80 
registers. It runs as a m/c subroutine to BASIC in effect.not an alternative oper- 
ating system but an extension in m/c of the ZX-21/TS1000 built-in operating system, 
At and F' registers and others used by the ZX/TS operating system are forbidden and 
the BC pair returns error number of track accessed when error encountered, to BASI 
and to print on the LDOS screen, just as with normal ZX/TS m/c subroutine calls. 
Even code saves do require a file name to save the item under, (to appear on the 
directory}, so mc routines using code save will also have to POKE this to CLINE, 
along with the SAYE” that precedes it. There is litle on m/c access of LDOS in our 
book, but some of the concepts involved and hardware analysis that might be helpful 
is included, Both the procedures andalso many concepts introduced while describing 
BASIC routines to dothe same or similar disk access tasks as needed in Co 

So that is the way LDOS can be handled by the programmer, with little effort. 
All this has been on simply saving and loading programs only with our LDOS system, 
he programm 


and in the simplest ways. There is much more the er can do with LDOS%t 
With all these details, we could Listing #3 Save for Self-starting Program 
make a final, fancy save routine for 9500 REM DISK SAVE (GOTO 9500 when saving 


a self-starting on loading program — 
in BASIC. It ts at Listing 43° right, 2210 SLOW 


9520 CLS. 

stem can 

‘ie Oe eee 9530 RAND PI#*PIWSR VAL"14336" 

they are all short! ae gens Bene a ER 

capacity is about 156K, or 1960 bytes 

ner raok and 79 data tracks, track 9560 PRINT"VERIFY/ DIRE? (Y OR N)” 

zero (top, outermost track) reserved 9570 IF.INKEY$ ="N" THEN GOTO SGN PI 
for a list of names of programs/ files 9580 IF INKEY$<®"Y" THEN GOTO VAL"9570" 
that are saved on the disk and a B.A.T, 9590 RAND PIxxPI+USR VAL"14336" 

table of whether each track is used 9595 REM DIRE 

or not. There are no sectors used in 9599 ....halts anyway on LDOS dire ... 
this disk system (LDOS), 5 inch DSDD (or 9599 GOTO SGN PI and not 9560-9595) 
disks are the only kind worth using, we cia 

(even tho the saving is in single- x Important note:Special lines 9560 
density form, use DD disks and drives), to 959% are to be used only when 
And you should always check after a program not completed, still being 
save to make sure the program is on changes/ improved. Distribution 
che QJRE list using a non-zero number versions Must have these iines 

of 1960 byte blocks. (Ø means no savel) removed from the program. 


Text Editing With The ZX-81/TS1000—Looking For A Substitute For INKEYY ree 

To write vour own wordprosessor in 72k-8Y TS1000 BASIQ you start with a dilemma, 
You must use Citner INPUT or INKEY; to get data irom the eyboard, INPUT will on 
the TX-31/TS1007 only allow you to put the material that you are typing, key-by-key 
at the bottom of screen (line 23), and only when you press Enter/N-L key will it 
pe available to the BASIC program you are writing to be displayed as a body of text, 
with the other lines of wnat you are typing. Furthermore to edit the text, you 
would have to retype the whole line (or select part of i&, like one word, by print- 
ing a cursor opposite it in the block of text), and retype it from scratch. This 
“ill not make a professional looking screen editor for your wordprocessor,. The 
nlternative is to use INKEY! and take every character and add it to a string for 
RAY purposes, and at the same time, echo it (PRINT it) where it belongs, anywhere 
on the screen, The problem with this is every time you go to type a space lehe 
most freauently used character in English), the program will halt ona break. The 
easiest fix is to arbitrarily assign another k y, like "=" to be the space key, ao 
shat an INKEYS which gets "-" from the keyboard will have added on the next line or 
so of the program, 2 routine to convert "-" to " " (space). This of course is hard 
on the typist and the first time it is forgotten, the program halts on a BREAK, 
message/error D, It was this problem that motivated writing this piece. 

There must be a better way. Perhaps a machine code routine someone else has 
already written, could be easily found in the magazines, I thought. The first kind 
vould be amc substitute for INKEY} which would not halt on BREAK. This was 
found in an old issue of SYNTAX magazine, newsletter. Unfortunately it was not the 
whole solution, It could be adjusted to reject the space key but without breaking 
out of its little m/c routine, so it was really only useful for a wordprocessor 
using another key like "-" for space, and this mc instead of INKEY$ would merely 
prevent the user from halting the program with a BREAK accidentally by pressing 
she space key. Pressing the space key would do nothing. It would merely disable 
she space key by refusing to accept its keypresses as a valid input anc loop back to 
where it looks for the next keypress. Sort of half-a-solution, but the simplest. 

Cn looking at other routines and thinking it through, it seemed that the ideal 
solution would be a rewritten m/c subroutine version of INPUT, perhaps with a lot 
more features, A full-screen text editor all in machine code in other words, or 
mostly in machine code. That was something few folks would want to spend the time 
on, sines it would be time consuming. But it was bugging me that perhaps something 
more could be done with the INKEY$m,/c substitute. ‘So we will think of many! 

The essence of the INKEY$ m/c subroutine problem is that if you return from the 
subroutine, no matter what your routine converts space/ break to, when you are out af 
the m’c and back mBASIC and you still have your finger, even for a split second on 
the space/ break key, then the program will halt. Again, it means that you have to 
start adding more editing functions to your m/c routine in rewriting INKEY just as 
rewriting INFUT seemed to be leading in this labour intensive direction. However, 
a first try, lasting many hours, produced an improved INKEY$ substitute . which did 
not solve the problem, but showed many ways that could be tried, This version did 
reject all key combinations that would lead to non-standard character codes, except 
-hose useful to have on return to BASIC to use certain editing keys to trigger BASIC 
routines. The codes selected were of course ENTER/Newline, at 118, and also Rubout/ 
Delete/ destructive backspace (CODE=119), all four arrow keys and EDIT and FUNCTION. 
Some keys would merely be disabbled (shift "A", instead of producing the BASIC tomer 
STOP, would simply not respond to that key combination, but could still be used for 
"AN when the shift key was not pressed), Two more things to speed up its operat- 
ion, were added as features. For the regular keys, both the character would be 
printed on the screen when the key was pressed, and the character would be stored 
inside a single character string variable, ZŠ, by POKE to the variable table, in 
machine code though, not using BASIC POKE command, The machine code routine to 
accomplish this was relatively involvec for a little routine, taking up more than 
64 bytes., The problem of getting any routine to respond to spaces without RETurn 
from the machine code, is comrounded by the difficulty of not knowing how many 


races need be handled this way, maybe just OMe or mayb: whole line of them! That 
means some fancy promramming to update this space acc tion that would precede a 
rercular character which the INKEYS substitute coulc from, So the output of 
routine might be not just one character, but one c: preceded by up to a line 
ef spaces. (Flus a routine for limiting the spaces lated before Return from 
m c to one line's worth.) At this point the rewriti she INPUT routine was 
almest sturtin= to look like the easier route. Howey INKEY$ needs analysis, 


INKEYE Substitute Continued Dek 
Let us now examine some real machine code, A typical mc keyboard input 

routine will first capture the kevboard scan codes, which are not the same as 
the ZX-81/TS1000 alphanumeric codes, the Sinclair's answer to ASCII. These latte 
codes are obtained by usinr the ROM call, CALL O2BB (hex CDBBO2Z). But this will 
always return something, whether or not any key is pressed. In fact if no key 
is pressed, it will return FF as one of the two bytes this ROM subroutine out- 
puts to the HL register, so you must test L and if it is NOT FF then you have a 
lecitimate case of a key being pressed, Then it seems typical to make a second 
test, just to make sure, and then you will have the scan-codes sitting in the 
YW] recister. To find the scan codes, perhaps it would be handy to write a 
little program, since you miy need to find what codes you are looking for, if 
you want to catch any at the scan code stage, Here is what we might try:- 


labels 
NOP LG sblank place to store one scan code number 
NOP øg ‘blank place to store the other scan code no; 
CALL 02BB CDBB¢2 * get scan code into HL reg.s 
INC L 2C ; if you add 1 to FF you get zero 
JR NZ, ST 2ØFA ; if not zero try again, that is this 


detects the absence. of a keypress, 
the proper beginning state 
test again for keyscan codes 
put that tell-tale code in L in D 
if it is FF, INC will make it zero 
if L has number FF now we will know, 
and if so, no key was pressed so try again 
if it falis through, then a key has been 
pressed anc we want to put these into 
C «which is where the scanng code 
decoder used to get ZXCODEs wants them 
we load the address 16514 where most 


CALL 02BB CDBBØ2 i 
l 
> folks using the ZX/TS put their m/c 
b 
i 
’ 
, 
; 


LD D,L 55 


LD HL¥,082  21824¢ 


into the HL register 


LD (HL),B 7 This puts (FOKEs) the msbyte scan code 


INC HL 23 and this moves HL to point to next RAM 
LD (HL) ,C ype address where it puts lsb scan code 
RET cg so now you return from yourm/c subrt. 


having safely tucked the numbers into 

the first two bytes of the REM statement, 
1 REM (once you load the m/c with a 
BASIC routine or via your assembler, but 
remember to run the m/c by calling only 
the third byte, that is USR 16516 in 

this example where first number is 16514 


Listing eh to test scan codes 
and see now to get Keybeard 
keypresses using ROM routine call ' 


Cnce this is loaded into the first REM statement, with nothing ahead of 
chat REM statement in your BASIC program area, that is,no earlier line, you can 
use a routine like the following to read the scan numbers of any code you try: 
to get by pressing a single key or the shift key anc another key at the same time, 


190 SLOW 

110 PRINT AT 1,¢; (Sets position on screen to start PRINTing from, ) 
120 FOR X=1 TC 7 (either by PRINT A$; or is m/c equivalent RST 10hex) 
130 LET C=USR 16516 

140 PRINT PEEK 16514 Listin 2 

Fa aso 16515 BSTC routine to use with 
190 STOP oe #1 to display scan 


Typical numbers might be, "1" key, no shift, 253, 247 and with shift key 
pressed first and at the same time, 252, 247, which is the shifted (red letter) 
EDIT, on the same key, The first key scanning code, in the H register, coming 
out of the ROM call at O2BB hex, is one less, if the shift key is pressed, while 
the same code in the L register is used, shifted or not. But you cannot tell 
from just the L code, which key is pressed, since for example all the keys from 
2 to T, that half-row across, give L as 251. If you openned the keyboard you 
would see that one wire is joining the 5 keys together, enlaining it perhaps to 
those wi ha yane for electronics Anyway you need both numbers, and that is 
exactly what the ROM routine DECODE takes, from BC, to return the ZX-CODE,or 
at least its address in HL, (HL points to a spot in the DECODing table in ROM). 


NKEY$ Substitute Continued ; baa 
So what we have at this point in the building of our ultimate routine is a 
loop for detecting that no key is pressed, the desired initial condition for 
detecting a human taking their finger and then pressing a key, and a second loop 
that looks for a k2ypress (scanning code, lsbyte in L, not equal to FF). So the 
ROM routine that is called (by CALL 0238} does the actual port query to look at 
the wires that are arranged in a grid (matrix) to see which have been shorted to- 
gether when a human finger pushes a switch connecting tHe two or the membrane 
keyboard just pushes two wires together, otherwise separated by a plastic bubble, 
There is not much electronics here. Unlike for example an IBM PC which has some 
kevboard decoding chips right inside the keyboard, in the ZX/TS you just have 
wires crossing and the resultant byte pattern obtained by reading these 13 wires 
comine from the keyboard as they cross, when finger pressure is applied at one 
roint or another, In fact if you look at a Z2X=80 wiring diagram, five lines (one 
dimension of the matrix, from KBOÇ to KBO4, go to a 7415365 i.c. which is simply 
a hex-buffer with 3-state, enabled control passed to the Z-80's D6, while DO-Ds 
are the lines that KBDO-4 respectively are passed to via these buffers, The i.c, 
does not do any decoding and simply prevents the pressing of a key from shorting 
out any data lines on the databus when the Z-80 wants them for some other use, 
The other & lines from the keyboard are attached to address lines to accept pulses 
from the Z-80, or buffered by an i.c. 7415157 in the case of AlL and Al5, only 
Ag roing out of this chip being subject to the line (input) select feature of the 
chip. The other, non-buffered lines of the keyboard simply rely on the isolation 
rrovided by 1N414§ diodes between them and address lines A9-Al13. This is all to 
make the point that there is no decoding here, mainly buffers, and the decoding to 
ret the scan codes is done by software, the ROM routine used in the CALL O2BB, 
which polls these electronic lines with the Z-80 instruction IN, by port FE, and 
gets the scan codes by processing these raw inputs by a series of OR, CFP, RLC, etc. 
commands, so that if a key has been pressed, the HL register, loaded at first with 
-he data FFFF will be changed to another 2-byte scanning code by the time the rout- 
ine exits with a RETurn from subroutine ae having detected a keypress or having 
found no key pressed at the moment, The point is that Sir Clive kept costs down by 
keepins hardware to a minimum and replacing it with bits and bytes that are progranr 
meg into a ROM chip, at pennies to the byte, (although I have not actually figured 
the cost). It is a lesson to microprocessor system designers that with a Z-&0 
board, ROM, RAM and two chips, the 7415157 and 74LS365, and a membrane keyboarda, 
you could do much the same, (The Zx-80 is used as an example, since the wiring 
diagram shows explicitly what happens, while the same circuits in the ZX-81 are 
buried in the mysterious and uncharted insides of the UIA chip.) 
So that is how the scan codes are obtained electronically, that is very simply. 
This leads to further problems for the machine language programmer, in that you may 
want too versions of your m/e INKEYS or INFUT program, one for a hard-key keydeard 
and another for the membrane keyboard. The problem is that even with the original 
INEDYË routine, glitches and key-bounce often will give a false response, a key not 
pressed beinz the worst case, especially in response to a"Press Y for Yes, N for No, 
routine in your program which uses INKEYS and gives you no second chance, as a 
wordprocessing prorram would te correct your error, Various hardware and software 
fixes have been sug7ested over the years in the ZX/TS hobby group newsletters, but 
this still remains a hazard to be aware of. (Using"ENTER Y...." with INPUT was the 
fix this writer used, in frustration with the false INKEY$ responses, versus INKEY$Q 
So we left off in our story, at LD B,H and LD C,L (before the POKE part which 
wo shall not use in the real routine), and this is made to get the scan codes into 
the B and C register, which is where the next routine to be called, ROM routine for 
decoding the scan codes, to get Zk-alphanumeric codes, Sir Clives answer to ASCII. 
A CALL @7BD (hex CDBD@7) will call this subroutine and the output in the HL regist- 
er is NOT the ZX-CONE! It is a pointer, to the place in the ROM table beginning at 
address Q@7E where the ZX-81 codes can be PEEKed out. That is HL is not the code 


as given in the back of the ZX-81/TS1000 user manuals, G=space, 1=M], 2=..... but 

i- You use, Lp A IRGI; the byte in A will be tne ZX-CODE, (not HL, to say it again). 
when you get this far, you can see that you have trhee choices if you want to 

trap certain characters that the keyboard will produce but which may be useless or 

unexpected (not shown by the printing on the keytops), for your program. If you are 

tO use your mc IRSYs substitute réutine in a wordprocessor, you will not need the 

ch.racters, tokens like <>» and THEN (one-pyte) that are for editing a ZX-BASIC line. 


INKEY3 Sudstitute Continued p.6 
There are three approaches to it, the dirty one being that you do aot care if the 


Cc 
typist presses a key combination that results in an unexpected or garbage output, 
since it can simply be corrected by the typist when the problem is noticed, when 
undesired output is seen on the screen, antoher variation on the dirty method is 
+o screen out a range of chracters, like those cXk-CODES over 120. A surprising 
number of commerical apllications use-or allow these spurious key entries by. 

The second appraach is to clean up*the output by simply not allowing a given | 
combination of keys when they are pressed to produce any output. They are dead in 
-o far as that combination is concerned. For example the "1" keytwill output the 
TX-CODE for l, (29) but when shifted, no code, just go back and look for another, 
leritimate and acceptable keypress, rather than returning the unprintable EDIT 
“ith code 117. This is done in your machine code routine by dtecting this unwanted 
code, or range of codes, such as those higher than 128 (in the previous example), 
and jumping back (with a JR for example) to the start, ST as shown in listing ly 
everytime you get such an unacceptable code, 

The third approach is to detect these key combinations that would result ina 
spurious or uneeded code, and convert it to a standard code, In the last example, 
the shift/"1" keypresses, would normally produce an unprintable EDIT, CODE#117. 
Rut you could adc a routine to convert that to a "1", CODE#29, so that pressing 
the "1" key, with or without the shift key, would just produce a "1" output always. 
For the purposes of your INKEY} substitute routine, the keybaord has been redesign- 
ed, changed from one intended to edit ZX/TS BASIC programs, to a more standard, 
computer or data terminal one, The problem is that this can be a difficult, mean- 
inz involvins a lot of programming, approach. 

However, there are ways of sim;lifying the job, compared to putting in a rout- 
ine to trap every, perhaps, over 150, of these unwanted codes, using a separate 
routine for each code, This is to trap a range of codes. t is simple enough to 
reject any codes higher than 127, simply by testing the code in A after LD A,(HL), 
tnat is the ZX-CODE, and see if it is over 127. The little routine that follows 
does just that. 

Continued from Listing #1, after LD B,H and LD C,L j;puts scan codes in BC 


Listing 72 NOP NOP NOP NOP NOP NOP NOP*NOP j;allows space for scan coœ 
Adding these ; traps to be added maybe 
routines to CALL O7BD CDBDO7 ; calls DECODE routine to take 
the first part * scan codes in BC and return ROM 
of listing #1 - character table pointer (in) HL 
makes a simple RDP’ NOP NOP NOP ‘pointer value traps could be put! hee 
but customizable LD A, (HL) 7E ; applies pointer to ROM table and 
INVEY? substitute - extracts ZX-CODE and puts it in A 
9LET CaUSR 16516 CP 76 hex FE76 * looks for CODE#118, Newline-Enter 
gives you code JR Z END 28 05 ; if New-line-Enter don't print, etc. 
EBT. LyalyeCHRy C CP 40 hex FEO ‘any codes beyond "Z" other than 118 
builds string JR WC, ST 30 D9 . are rejected, key dead, try again 


RT 10 hex, LD _B,#00, LD C,A RET prei puts CODE in BC, prints char., ret.Ba&SIC 


C 

But this does not mean Wee there are not other ways of trapping these odd keys, 
You can trap on the ZX-CODE value, yes. You can trap on the scan-code value, 2- 
bytes, after CALL O2BB ...to...JR Z, AG, which offers a second alternative. And 
finally you can trap on values of the pointer HL, rather than the ZX-CODE it points 
to, after ROM routine (DECODE) is run by CALL O7BD, to process the raw scan codes, 
Why would you use this last method? The pointer numbers are grouped in certain 
ways, so that codes OOA9 (HL contents, pointer values in other words) to OOB6, will 
point to a group of Z -CODES, sprinkled over the CODE table,when viewed in numerical 
order, as seen in the back of your ZX/TS user manual, But a big hnnk of these codes 
that are obtained by pressing the shift key.at the same time as another key, put on 
the keytops in red ink, are useless except for ZX-BASIC program typing. Two compare 
commands can catch them. Then, simply subtracting hex-27 from the HL values, will 
make the pointer, point to their proper ZX-CODE, the one that would have been had, 
by pressing that key vith ut pressing the shift, Remember we are doing arithmetic 
and comrares on the pointer in HL, not the ZX-CODE, so that the ZX-CODEmmust be 
derives after thic process, by LD A,(HL). A trick routine, but a lean one. So, in 
summary, some combination of CONE, pointer and scan code trapping can mode pa ba 
nio Pathar., SOT Ss te r 7 r the 7X8] a] j e in 2 UW just 
2 rather sophisticated keyboard Jayout for she ook] and all conse the cx-e1/ S100. 
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Chaos And Computers — Chaos Describes More Than That Mess On Your Desk Ps 

What castles the mathematicians build in the air! Clear, clean line drawings 
of castles., Flat glissening smooth walls, perfect conical roofs on the towers, 
Unfortunately, that ain't real life, where the walls are pock marked, not mirror- 
smooth, the tower roofs rough shingled with hand-cut shakes and the lines broken 
with the shakes of an artist's hand, in spite of the attempt to hold it straight, 
to an unbroken, unwavering, idealized reality, 

There are many problems in engineering like this, The cases where the real, 

“nractical” spring does not fully return to its shape after being stretched, the 
stock market cycles that never repeat with perfect enough regularity to let any- 
one who can plot a simple curve with ruler and compass make a killing. The noise 
on the phone lines that turns your computer BBS download into a garbage collection 
of miscellaneous symbols from different languages and playing cards, and ... not 
at all the text on the latest tricks and tips that you expected. Attempts to 
chart the stock market or predict the occurence of interference on the phone lines, 
first were based on the assumption that the real world was liestraight lines and 
regular curves, beneath all the minor, bumpy imperfections that we all see when 

we look at the world. The underlying reality was the smooth perfection and stra- 
ight lines that form the three dimensions, the one-dimensional line, the two-dim- 
ensional plane with X and Y axes, and the three dimensions of solid objects, that 
have a volume and therefore a weight. Or so thought the mathematicians, 

But math crows too, Mandelbrot, a mathematician from France, ensconced in a job 
at IBM in the USA, studied the noise problem that plagues data transmission for 
IBM, and found that maybe the theory of underlying regularity, superficial imper- 
fections in real life, superimposed on them, would not heip in designing error 
proof systems. If that were the case, simply stepping up the power, current and 
voltage, of the underlying regular transmission, and you would overcome the effect 
of the little imperfections that represented the noise, Unfortunately every time 
the signal power was stepped up, some amount of the noise was often sufficient to 
block the correct signal and substitute an error for it, Mandelbrot decided that 
the mathematical theory to explain this was that the reality of noise was not of a 
minor imperfection superimposed on an underlying perfect reality but the noise was 
of equal reality (and strength potential) to the signal, Suggestion to IBM: just 
check for the errors and correct them when detected (by retransmission for example) 
rather than trying to drown them out. Suggestion for mathematicians: maybe the 
imperfections in the real world compared to the smoothness of the ideal world of 
conventional geometry, where curves never start and stop but go through all the 
points separating their beginning from their end, maybe that mathematics does not 
describe all phenomena in the world, Should not limit the idea of legitimate math 
compared to curious anomalies and mathematical paradoxes, Suggestion for geometers 
is that maybe this geometry of our imperfect world, the rough surface reality is nt 
best described always in a geometry of dimensions like 1, 2 and 3, that is dimens- 
fenge whole numbers. You can use S 4 or 0.2187 as dimensions too, a fractional 
dimension world, where 14 diminsions is a legitimate reality, and from this, came 
the word fractal. But this is just one fascinating story from the book, Chaos, 
Making A New Science, Penguin paperback, 1987, by J. Gleick, that has become a 
classic in the literature explaining science to the citizen scientist, that is all 
of us, The treatment is based on personal stories of the discoverers of this new 
mathematics, and the informal, friendly way in which they talk to the reader rat- 
her than over his (or her) head is rare in popularizations as is the breadth and 
detail in which the story is told. 

The TAB, book of 1989 on Chaos, by E., Rietman, Exploring the Geometry of Nature 
is probably a good follow-up for the reader of the First book that wishes to Look 
into some of the actual mathematical equations involved or try the GWBASIC routines 
while the illustrations in Gleick are mainly pictures rather than equations, fet 
another introduction to the field is an article in Scientific American magazine, 
which does have some spectacular pictures and the usual level of text to accompany 
them which the reader has come to expect of this semi-technical popular magazine, 
(Nov.8l and ), These sources do not exhaust the popularizations coming to 
a bookstore near you (or a library), since books on this important and fascinating 
result of the ability of computers to calculate and plot the massive numbers of 
points involved in studying this field, are being issued just as researchers are 
discovering new applications and rules for this science. Just when we thought that 
all the important math had been invented long ago, here comes chaos! 
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If you look at the floppy disk drive of your computer, you probably have to 
strain your imagination to remember how it was with computers before disk drives 
were invented. In those days, electronic. memory was expensive and most pre-1970 
computers relied on cheaper, bulkier forms of mamory, even solid magnets (core 
storage) for RAM and even before magnetic tape drives, punched paper tape and the 
punched cards the size of an old US dollar bill were trfed. Such media needed big 
buildings fr permanent storage of programs and data. Unfortunately also punched 
paper or cardboard devices were very slow due to their mechanical nature, feelers, 
wheels and their momentum and size, only capable of a certain speed of being 
pushed around before they bacame inacurrate or floated between binary 1 and zero, 
not touching anything. In fact, the main progress of electronic computers has been 
to save on the size cfthe physical objects used to represent binary 1 and O, from 
the mechanical calculators’ one-inch diameter wheels down to tiny bunches of 
electrons that respond to a push with the speed of light, and for which a push 
may take only a tiny bit of energy. Making a mechanical computer is possible, 
but the size of it and energy to push the wheels around even slowly, would make it 
skyscraper-sized to do even the simplest practical work, When mechanical devices 
are governed by limits of inertia (momentum)=weight x speed (physicists use the 
more precisely framed mass and velocity, mv,if you are going to be looking this 
up in a reference book) then reducing the weight by reducing the size of each part 
of a computer used to represent a binary bit is obviously the way to go, and the 
way computer science has gone, The complexity of the logical and math problems 
(even addition) that computers need be used to solve to be useful, means many 
binary bits and many, many parts used to physically represent them, too many for 
mechanical computers to be useful except in a pinch, when nothing else was .avail- 
able. As for using magnetic s rage on tape instead of mechanical storage on 
punched paper tape or punched cards, the same sort of efficiencies could be had 
by magnetizing a very tiny area on a ferric oxide coating on plastic tape as 
opposed to making a rather large hole in paper or cardboard. 

It seems we take computers so much for granted now that we forget that they are 
purely physical ways of working out arithmetic and other information and logical 
problems, much the way ancient civilization's accountants used to, for example 
divide 121 apple baskets into three by taking 121 beans and splitting them into 
three equal sized groups, and then a simple count of one group could tell how 
many apple baskets would be one third (and how many would be left over), 

This is simply a tase of letting small, physical objects represent numbers to be 
divided, added , subtracted, compared, etc. Computers just use electrons and 
magnetizable areas on a magnetic tape or disk to physically represent numbers 
rather than beans, but the principle is the same. So much for bean counters, 

Early tape drives for computers of the 1950's and 1960's did put a lot of 
binary data in a small space, the commonest standard being to use 8 parallel tracks 
to save on the length of tape needed to store data of a large blocks, But if you 
look at an old movie of a computer of this time, the reels of tape are always 
Spinning as the computer tries to find chunks of data on different spots on the 
tape. So the speed problem became critical as computers got faster and needed to 
look things up on the tape faster, The mechanisms became a speed bottleneck. 

An engineer from IBM had a better idea after taking a lunch break at a diner 
that had a juke box. He reasoned, if so much data was needed to be looked up 
that could be found only at unpredictable (mathematically speaking, random from the 
analytical model used to think of the problem) locations on the tape, perhaps a 
tape was not the best shape of magnetic medium to use. A disk, like a phonograph 
record would allow one to get to any track on it without nearly as much physcial 
movement he reasoned, and so the disk drive was born. It was a matter of, as with 
a long playing phonograph record, moving the arm to the right track, rather than 
spinning a reel of tape, many feet along the thread of data written on it, that 
saved physical movement to speed things up. A genius sort of inspiration! Of 
course, a phonograph record has its track in a spiral form so the music will not 
be interrupted as it would be if the tracks were all circles, closing in on them- 
selves, but the computer, very interrupt tolerant did not need this and so the 
computer disks used non-overlapping circles one inside the other as the tracks to 
Store the data magnetically on, as used to this day, and in one Single line of 
binary bits. A bit stream, when geen. electronically at the electronic circuits 
that feed the electro-mechanicil part of the disk drive's data handling picturesit 

So IBM put its first disk drive on the market in 1957. It was a hard disk, 
vith a removable stacked disk unit, magnetic coating on aluminum base,disks, and 
it was about waist high with a plastic cover to keep out dust that would otherwise 


obscure the tiney magnetic spots where a binary bit was stored on a track on it. 
And that is how it all started} 


